Hilfe! Kompatibilitätsproblem- Unterschiede zw. 1200XL vs 600XL

← Zurück zum Forum

Kveldulfur 20.05.2025 07:36

Hallo Leute!

Ich programmiere z.Zt. Schränker 4 und es läuft echt gut. Auf dem Altirra funktioniert alles perfekt... auf dem 600XL+ läuft das Spiel ebenfalls ohne Probleme. Das Spiel nutzt 64kB, also auch den RAM unterm ROM, ansonsten hat es keine Besonderheiten.

Nun hat Peter das Spiel auf dem MacEmulator testen wollen und alles funktioniert, nur meine Spielfigur kann nicht fallen? Springt man hoch, bleibt sie in der Luft stehen... schon echt irrer Fehler. Aber auf org. Hardware geht es, also keine Aufregung, liegt am Emulator.

Nun ließ mir das keine Ruhe, also habe ich mein Spiel auf meinem 1200XL getestet... und was soll ich sagen. Funktioniert alles perfekt, bis auf das meine Spielfigur in der Luft stehen bleibt, wie beim MacEmulator. Das ist schon etwas seltsam... zumal alles andere funktioniert. Wenn ich "in der Luft" zu einer Platform gehe, die sich vertikal bewegt, wird meine Spielfigur mitgenommen. In beide Richtungen. Gehe ich von der Plattform, flieg ich wieder.

Irgendeine Idee?

Da ich aktuell nur den 600XL+ und den 1200XL nutzen kann, weiß ich nicht, wie andere ATARIs reagieren. Altirra ist es übrigens egal, ob NTSC, PAL, 50Hz oder 60Hz... da funktioniert das Spiel immer.

Bitte um Hilfe... Janko

Meine Projekte findest Du hier...

Kveldulfur 20.05.2025 08:04

Hallo!

Bin natürlich kräftig am Suchen und habe nun herausgefunden, dass es am Betriebssystem liegt. Wenn ich beim Altirra das AltirraOS nutze, funktioniert das Spiel nicht. Alle anderen Betriebssysteme (ausser Ultimon XE) laufen. Das 1200XL-OS geht immer in den Selftest... daher kann ich es nicht prüfen. Ob es daran liegt? Aber wieso, das OS schalte ich eigentlich ab, wenn man ein Level spielt.

Grüße Janko

Meine Projekte findest Du hier...

Irgendwer 20.05.2025 08:57

Wenn Du das OS abschaltest bzw. Speicher unter dem OS nutzt, wirst Du sicherlich ein paar Vektoren verbogen haben/müssen. Zeigen die vielleicht auf OS-Routinen und nutzen sie dann wirklich die "offiziellen Einsprungsadressen"? (...nur mal so als Vermutung...)

Kveldulfur 20.05.2025 09:37

Moin!

Sobald ich dann das Spiel mit START beginne, wird das Level geladen und angezeigt. In dem Moment, in dem man aktiv spielt, ist das ROM komplett abgeschaltet. Sämtliche VBI/DLI laufen direkt in meine eigenen Routinen.

Ab diesem Zeitpunkt hat das OS also keinen Einfluss mehr auf das Spiel. Alles ist extrem zeitkritisch, aber es läuft perfekt: Farben, Musik, Gegner – alles stimmt.

Ich berechne die Position der Spielfigur und den entsprechenden Bildschirmspeicher. Befindet sich dort eine „0“, also Luft, fällt die Figur. Es wird auch „nichts“ angezeigt auf dem Bildschirm unter der Figur – es muss also eine „0“ sein. Wenn ich sterbe und das Spiel beendet wird, gelange ich ganz normal ins Menü zurück, kann neu starten usw.

Wieder so ein Rätsel, um das ich nicht gebeten habe. 😀

Selbst wenn das OS beim Laden etwas in der Zero Page verändert, wird beim Spielstart alles neu initialisiert. Vektoren verbiege ich keine – denn wenn das ROM deaktiviert ist, liegen im Bereich $FFFA bis $FFFF meine eigenen Routinen. Ist das ROM aktiv, stehen dort natürlich die Einsprungadressen des OS. Aber das ROM ist wirklich nur während der Ladevorgänge aktiv – also meistens deaktiviert.

Grüße Janko

Meine Projekte findest Du hier...

Dr. Irata 20.05.2025 10:12

erstaunlich, daß der Player echt in der Luft hängt und dort bleibt... also nicht runterfällt...

Irgendwer 20.05.2025 10:41

Kveldulfur schrieb: Alles ist extrem zeitkritisch, aber es läuft perfekt: Farben, Musik, Gegner – alles stimmt.

Wieder nur ein Verdacht, aber AFAIK ist der 1200XL original eine NTSC maschine. Kann es sein, dass einfach für 60 Updates pro Sekunde im VBI die Zeit fehlt und der VBI (wie meistens) nicht re-entrant ist?

Kveldulfur 20.05.2025 11:01

Hallo Leute!

Erst einmal danke für die Hilfe! Ich habe den Fehler gefunden... hat ja nur ein paar Stunden gedauert 🙂 Also, der Fehler ist ein Flüchtigkeitsfehler, der sich perfekt getarnt hat und nur durch die OS-Wahl aufgedeckt wurde.


        ; Nach Feuer suchen als Untergrund
?SearchFeuer    LDA (TEMP01),Y
        AND #%01111111       
        CMP "!"         ; # Unsichtbar          
        BEQ ?FoundGround
        CMP #$39        ; # "Y" Feuer
        BCC ?SearchNext
        CMP #$3d        ; # $3d = "\" Feuer
        BCC ?FoundGround

Diese Routine, die eigentlich Feuer suchen soll, wurde von mir ergänzt, weil es gut passte, um das Ausrufezeichen. Das ist ein unsichtbares Zeichen im Spiel, womit ich Objekte, die selbst nicht als Boden definiert sind, zu einem Boden machen kann. CMP "!" ist also gleichbedeutend mit CMP $01 Jetzt erkennt man schon direkt, dass dort das Hashtag fehlt... also CMP #$01 müsste es heissen. Nun der Fan-Fact: Im XL/XE-OS steht an der Speicherstelle $01 (NGFLAG) eine 1 (RAM/ROM-Test ohne Fehler) und somit funktionierte alles. Im AltirraOS (und vermutlich 1200XL-OS) steht an der Speicherstelle $01 eine 0, womit plötzlich die gesamte Luft zum Boden wird.

Kleiner Fehler... große Wirkung 😁

Man, habe ich jetzt Kopfschmerzen...

Grüße Janko

EDIT: Eben auf dem org. 1200XL gespielt... keine Probleme mehr 😁

Anhänge:

post_Kveldulfur_2025.05.20_11:01.md~

Meine Projekte findest Du hier...

Mathy 20.05.2025 13:12

. Hallo Janko

Kveldulfur schrieb: Man, habe ich jetzt Kopfschmerzen...

Das sind die neuen Synapsen die sich jetzt bilden... 😉 😀 😂 😁

Tschüß

Mathy

Schreibe nicht der Absicht zu, was man mit Dummheit oder Ignoranz erklären kann.

slx 20.05.2025 20:52

Mein Beileid! So einem vergessenen Hashtag verdankte ich als Teenager meine erste durchwachte Assemblerprogrammiernacht. Wenn man nach Dutzenden Versuchen draufgekommen ist, dann ärgert man sich über die sinnlos verbrauchte Zeit…

Dr. Irata 20.05.2025 22:15

... Klassiker ...

mega-hz 20.05.2025 23:51

wie wäre es wenn man definitionen anlegt?

BODEN  .byte 01

CMP BODEN

usw.

Sowas hab ich mir seit der Arduino C-Programmierung angewöhnt, da auch ich früher nächtelang um den eigentlichen Fehler herumprogrammiert habe. Nächsten morgen dann nach nem frrischen Kaffee hats dann "klick" gemacht und ich hab mich über die verschenkte Zeit geärgert...

keine PN's mehr! Bitte per email kontaktieren! atari1450xld©mega-hz.de

DjayBee 21.05.2025 04:46

Gelöscht weil Käse.

Kveldulfur 21.05.2025 05:46

mega-hz schrieb: wie wäre es wenn man definitionen anlegt? BODEN .byte 01 CMP BODEN

Hallo!

Das wäre eine eher schlechte Idee. Konstanten definiert man mit EQU

BODEN           EQU $01

Allerdings benötigt man dann weiterhin ein Hashtag, wenn man den Wert selbst nutzen möchte und nicht die Adresse. Ausserdem erkenne ich durch #"!" sofort, dass es in dem Fall um das Ausrufezeichen geht, weshalb ich diese Nutzung sinnvoller finde.

Aber nun zu Deinem Beispiel:

BODEN           .byte $01
...
        CMP BODEN

Generell hast Du Recht, dass man hier kein Hashtag mehr benötigt. Man erkauft sich das aber durch folgende Nachteile:

Wenn "BODEN" in der Zeropage definiert ist, benötigt dieser Befehl 2 Bytes und 3 Rechenzyklen
Wenn "BODEN" ausserhalb der Zeropage definiert ist, benötigt dieser Befehl 3 Bytes und 4 Rechenzyklen

Normal benötigt dieser Befehl mit der Nutzung einer Konstanten (Immediate) 2 Bytes und 2 Rechenzyklen. Da die Zeropage nicht soviel Platz bietet, würde man also statt 2 Rechenzyklen, die doppelte Anzahl benötigen. Was wiederum bedeutet, dass man in der selben Zeit nur 50% der Abfragen machen könnte! Wenn das dann konsequent so gemacht wird, verschwendet man eine Menge Rechenzeit und die ist echt kostbar.

Grüße Janko

Meine Projekte findest Du hier...

Dr. Irata 21.05.2025 08:05

Mann muss ja auch das Rad nicht schlechter und neu erfinden, weil man so vielleicht einen möglichen Bug weniger hätte... einfach den # verwenden und schon gehts ja wie gewünscht 😉

Dr. Irata 21.05.2025 17:34

Hey Janko, vielleicht magst du ja mal einen eigenen Artikel / Post übers RAM unter ROM mit Abschalten des OS und eigenen Routinen hier gut erklärt mit entsprechenden Routinen präsentieren... damit jeder es nutzen kann und weiß wie es funktioniert und worauf man da achten muss... LG Peter

mega-hz 21.05.2025 19:49

Das geht doch recht einfach... Vorraussetzung ist, daß Dein Programm rein garnix vom OS benutzt. Also auch VBI,DLIs usw. nicht. Dann einfach mit $FE in $D301 das OS abschalten und schon ist von $C000-$FFFF Ram. Vorher noch die IRQs die auf das OS evt. zeigen, deaktivieren... (Natürlich nicht bei den Hardwareregistern $D000-$D7FF)

keine PN's mehr! Bitte per email kontaktieren! atari1450xld©mega-hz.de

mega-hz 21.05.2025 19:51

Kveldulfur schrieb:

mega-hz schrieb: wie wäre es wenn man definitionen anlegt? BODEN .byte 01 CMP BODEN

Hallo!

Das wäre eine eher schlechte Idee. Konstanten definiert man mit EQU

BODEN EQU $01

Allerdings benötigt man dann weiterhin ein Hashtag, wenn man den Wert selbst nutzen möchte und nicht die Adresse. Ausserdem erkenne ich durch #"!" sofort, dass es in dem Fall um das Ausrufezeichen geht, weshalb ich diese Nutzung sinnvoller finde.

Aber nun zu Deinem Beispiel:

BODEN .byte $01 ... CMP BODEN

Generell hast Du Recht, dass man hier kein Hashtag mehr benötigt. Man erkauft sich das aber durch folgende Nachteile:

Wenn "BODEN" in der Zeropage definiert ist, benötigt dieser Befehl 2 Bytes und 3 Rechenzyklen

Wenn "BODEN" ausserhalb der Zeropage definiert ist, benötigt dieser Befehl 3 Bytes und 4 Rechenzyklen

Normal benötigt dieser Befehl mit der Nutzung einer Konstanten (Immediate) 2 Bytes und 2 Rechenzyklen. Da die Zeropage nicht soviel Platz bietet, würde man also statt 2 Rechenzyklen, die doppelte Anzahl benötigen. Was wiederum bedeutet, dass man in der selben Zeit nur 50% der Abfragen machen könnte! Wenn das dann konsequent so gemacht wird, verschwendet man eine Menge Rechenzeit und die ist echt kostbar.

Grüße Janko

Hmm, Zeropage? Ich meinte eigentlich nur im WUDSN Assembler Variablen einen Wert zuweisen die rein "nur" für den Menschen als Ersatz für Werte stehen. Der Assembler müsste dann doch aus CMP BODEN ein CMP #$01 machen...

keine PN's mehr! Bitte per email kontaktieren! atari1450xld©mega-hz.de

Dr. Irata 21.05.2025 21:30

mega-hz schrieb: Das geht doch recht einfach... Vorraussetzung ist, daß Dein Programm rein garnix vom OS benutzt. Also auch VBI,DLIs usw. nicht. Dann einfach mit $FE in $D301 das OS abschalten und schon ist von $C000-$FFFF Ram. Vorher noch die IRQs die auf das OS evt. zeigen, deaktivieren... (Natürlich nicht bei den Hardwareregistern $D000-$D7FF)

... wenn du das so machst, klingt es natürlich zunächst recht einfach, dann ist der Rechner quasi aber fast tot! Bringt also eigentlich nichts... wir wollen ja aber das ROM bzw. das OS abschalten, um den RAM unter ROM nutzen zu können, bestimmte Dinge brauchen wir aber dann dennoch. VBI, DLI, Joystickabfragen, bestimmte Routinen bzw. Register werden gesetzt werden müssen, Player/Missile, Tastatur... also da ist schon einges, was man beachten und definieren muss. Dafür wirft man aber den ganzen Ballast ab, den man vielleicht gar nicht ständig braucht ...

Kveldulfur 21.05.2025 22:23

mega-hz schrieb: Hmm, Zeropage? Ich meinte eigentlich nur im WUDSN Assembler Variablen einen Wert zuweisen die rein "nur" für den Menschen als Ersatz für Werte stehen. Der Assembler müsste dann doch aus CMP BODEN ein CMP #$01 machen...

Hallo!

Das was Du meinst ist keine Variable sondern eine Konstante und die wird per EQU zugeweisen. Eine Variable ist während der Ausführung änderbar und belegt somit eine Speicherstelle, dass geht z.B. mit ".byte".

    ORG $0600
ConstA  EQU $05
VarA    .byte $01

In dem Beispiel wird die Speicherstelle $0600 mit dem Wert 1 belegt. Du kannst über den Bezeichner "VarA" statt $0600 nutzen. Ein "cmp VarA" ist also ein "cmp $0600" und greift auf den Inhalt der Speicherzelle $0600 für den Vergleich zu.

ConstA belegt keinen Speicher, sondern wird sich nur während des Compiliervorgsang gemerkt und eingesetzt. "cmp #ConstA" bedeutet "cmp #$05: Vergleiche mit der Zahl 5. "cmp ConstA" bedeutet "cmp $05": Vergleiche mit dem Inhalt der Speicherstelle $05.

Eine Definition, dass "Boden = #$01" sein soll, gibt es meines wissens nicht und würde auch das Lesen des Quellcodes erschweren.

Grüße Janko

Meine Projekte findest Du hier...

Dr. Irata 21.05.2025 22:48

ja... theoretisch könnte man folgendes coden:

BODEN          .byte 01

....
                       cmp BODEN

In diesem Fall steht an der Speicherstelle BODEN der Wert 01 und mit cmp BODEN wird dann vom Akkumulator der Wert in Boden (also 1) abgezogen. Darauf folgt dann z.B. der branch Das geht schon, erscheint allerdings umständlich. Lieber gleich an die richtige Syntax mit dem #1 denken!!

Kveldulfur 22.05.2025 06:01

Dr. Irata schrieb: Hey Janko, vielleicht magst du ja mal einen eigenen Artikel / Post übers RAM unter ROM mit Abschalten des OS und eigenen Routinen hier gut erklärt mit entsprechenden Routinen präsentieren... damit jeder es nutzen kann und weiß wie es funktioniert und worauf man da achten muss... LG Peter

Hi!

Im Prinzip ist es, wie Wolfram es schreibt.

Mit folgendem Code:

        SEI     ; IRQ sperren
        LDA #$00    ; VBI + DLI unterdrücken
        STA NMIEN

        LDA #$FE    ; OS und Basic abschalten
        STA $D301   ; PORTB

schaltet man NMI und IRQ aus – und kann anschließend das ROM deaktivieren.

Fertig 🙂

Man kann den ATARI auch komplett ohne Interrupts betreiben. Man muss dann allerdings das Timing selbst exakt steuern… Deshalb ist es dann doch evtl. einfacher zumindest den NMI zu nutzen, weil der ANTIC einem dann ein wenig das Timing abnimmt.

Wenn das ROM abgeschaltet ist und man weiterhin Interrupts nutzen möchte, muss man sicherstellen, dass gültige Vektoren für den NMI und IRQ im RAM untergebracht sind:

$FFFA/$FFFB – Vektor für die NMI-Routine (für VBI/DLI)
$FFFE/$FFFF – Vektor für die IRQ-Routine (z. B. Tastatur, POKEY)

Im Spiel nutze ich in der Regel nur den NMI. Den IRQ-Vektor setze ich einfach auf einen RTI, und durch SEI stelle ich sicher, dass kein IRQ während meines "zeitkritischen Codes" dazwischen funkt. 😉

Die NMI-Routine muss zuerst prüfen, ob es sich um einen DLI oder VBI handelt. Hier bietet sich der gleiche Mechanismus an, den auch das OS nutzt:

        BIT NMIST
        BPL ?VBI
        JMP (VDSLST)

Mit BIT NMIST wird Bit 7 ausgewertet. Bei einem VBI (Bit 7 = 0) wird nach ?VBI verzweigt, ansonsten folgt ein Sprung zum DLI-Vektor in VDSLST.

Was in ?VBI passiert, hängt ganz vom Anwendungsfall ab – im einfachsten Fall reicht hier sogar schon ein RTI, wenn man DLI exklusiv nutzt. Wichtig: VDSLST muss natürlich gesetzt sein, bevor man den DLI aktiviert. 😉 Viel mehr ist es nicht.

Vorteile dieser Methode:

Der RAM unter dem ROM kann genutzt werden
Die VBI-Routine ist entweder deutlich schlanker – oder wird ganz entfernt, was Rechenzeit spart
Die ZeroPage und der Bereich der Schattenregister ist theoretisch für eigene Zwecke frei verwendbar

Beim letzten Punkt muss man aber vorsichtig sein, möchte man nämlich zwischendurch doch das OS nutzen, sollte man diese lieber unangetastet lassen. Man beachte auch, dass ein RESET das OS wieder einschaltet, weil $D301 zurück gesetzt wird.

Grüße Janko

Meine Projekte findest Du hier...

Irgendwer 22.05.2025 10:40

Nur der Vollständigkeit halber: Es geht natürlich auch das RAM unter dem OS zu verwenden UND dem OS die Interrupts & Co zu überlassen. In einer Routine im "normalen" RAM liegt dann ein Mini-IRQ-Handler der * das OS einblendet * die OS-Vektoren anspringt * das OS wieder ausblendet und somit dem Hauptprogramm den Zugriff auf das RAM unter dem OS ermöglicht.

Um Überraschungen zu vermeiden: Der Zeichensatz ist auch Teil des OS'. Sollen Buchstaben weiter sichtbar sein, muss ein eigener bzw. eine Kopie vom Zeichensatz im Speicher bereitgestellt werden der gerade verfügbar/eingeblendet ist...

Einige Threads bei AA beschäftigen sich auch mit dem Thema - wo es auch Beispielcode gibt:

https://forums.atariage.com/topic/136677-code-under-os-rom/ https://forums.atariage.com/topic/234080-under-the-os/ https://forums.atariage.com/topic/280971-using-xl-memory-without-breaking-stuff/

Edit: ...und im Atari-Wiki gibt's auch Code für ACTION!: https://atariwiki.org/wiki/Wiki.jsp?page=Using%20the%20RAM%20Under%20the%20OS%20ROM%20on%20XL%20and%20XE%20Computers

mega-hz 22.05.2025 19:10

Kveldulfur schrieb:

mega-hz schrieb: Hmm, Zeropage? Ich meinte eigentlich nur im WUDSN Assembler Variablen einen Wert zuweisen die rein "nur" für den Menschen als Ersatz für Werte stehen. Der Assembler müsste dann doch aus CMP BODEN ein CMP #$01 machen...

Hallo!

Das was Du meinst ist keine Variable sondern eine Konstante und die wird per EQU zugeweisen. Eine Variable ist während der Ausführung änderbar und belegt somit eine Speicherstelle, dass geht z.B. mit ".byte".

ORG $0600 ConstA EQU $05 VarA .byte $01

In dem Beispiel wird die Speicherstelle $0600 mit dem Wert 1 belegt. Du kannst über den Bezeichner "VarA" statt $0600 nutzen. Ein "cmp VarA" ist also ein "cmp $0600" und greift auf den Inhalt der Speicherzelle $0600 für den Vergleich zu.

ConstA belegt keinen Speicher, sondern wird sich nur während des Compiliervorgsang gemerkt und eingesetzt. "cmp #ConstA" bedeutet "cmp #$05: Vergleiche mit der Zahl 5. "cmp ConstA" bedeutet "cmp $05": Vergleiche mit dem Inhalt der Speicherstelle $05.

Eine Definition, dass "Boden = #$01" sein soll, gibt es meines wissens nicht und würde auch das Lesen des Quellcodes erschweren.

Grüße Janko

Ja wie Keveldur schon sagte, VBI,DLI usw. muss man dann selber machen!

keine PN's mehr! Bitte per email kontaktieren! atari1450xld©mega-hz.de

Dr. Irata 23.05.2025 08:08

... wie gesagt, wir diskutieren hier über ein Bug im Code. Also ein vergessenes # was dazu führt, daß das Programm an dieser Stelle nicht mit dem Wert vergleicht, sondern mit der Speicheradresse. Wenn ich also aktuellen Akku-Inhalt mit cmp #1 vergleichen möchte und das # vergesse, dann bewirkt cmp 1 einen Vergleich mit Speicherstelle 1. Wenn da nun zufällig der Wert 1 drin steht, dann läuft alles wie gewünscht und man merkt den Fehler gar nicht. Ist mir auch schon passiert. Wenn da jetzt ein anderer Wert drin steht, dann gibt es entsprechende Programmfehler. Ganz blöd wird es, wenn unterschiedliche Werte dort reinkommen, dann kann es zu Fehlern führen, die man nur sporadisch bemerkt und die schwer zu finden sind. Man muss dann detektivisch die entsprechende Routine finden, die dafür verantwortlich ist. So haben wir es ja auch in diesem speziellen Fall gemacht und Janko hat dann schnell den fehlenden # gefunden.

Im Vorfeld alternative langsamere Definitionen zu finden, um diesen Bug zu umgehen machen m.E. keinen Sinn. Dann kommen andere Bugs...

cpg 31.07.2025 16:37

Irgendwer schrieb: Nur der Vollständigkeit halber: Es geht natürlich auch das RAM unter dem OS zu verwenden UND dem OS die Interrupts & Co zu überlassen. In einer Routine im "normalen" RAM liegt dann ein Mini-IRQ-Handler der * das OS einblendet * die OS-Vektoren anspringt * das OS wieder ausblendet und somit dem Hauptprogramm den Zugriff auf das RAM unter dem OS ermöglicht.

Um Überraschungen zu vermeiden: Der Zeichensatz ist auch Teil des OS'. Sollen Buchstaben weiter sichtbar sein, muss ein eigener bzw. eine Kopie vom Zeichensatz im Speicher bereitgestellt werden der gerade verfügbar/eingeblendet ist...

Das ist grob (oder besser genau) gesagt das was das "atarixl" Target für cc65 macht.

slx 05.08.2025 07:04

Dr. Irata schrieb: ... Im Vorfeld alternative langsamere Definitionen zu finden, um diesen Bug zu umgehen machen m.E. keinen Sinn. Dann kommen andere Bugs...

Es wäre nur dann nicht (bzw. nur beim Kompilieren) langsamer, wenn es eine Textsubstitution oder ein Makro wäre. D.h. würde man ein Makro „.isboden“ mit „CMP #“!“ definieren, dann gäbe es nur mehr eine Gelegenheit, den Fehler zu machen.

Erst kürzlich wieder wo gelesen: ein wichtiger Grund für die Entwickelung von Hochsprachen war, dass Programmierer damit produktiver sind, weil es weniger zu tippen und weniger Möglichkeiten, Fehler zu machen gibt.